For integrated circuits that include a memory array, the matrix memory cells are usually tested and, if necessary, repaired before the circuits are shipped to customers. If a matrix cell is found to be defective, it is replaced with a redundant memory cell. Specifically, an address decoder is programmed to map the redundant cell to the address of the defective matrix cell and to disable data access to the defective cell. Therefore, when an external circuit reads data from or writes data to this address, the address decoder deactivates the defective matrix cell, activates the redundant cell, and reroutes the data from (read) or to (write) the redundant cell. The rerouting and disabling program executed by the address decoder is often called the repair solution for the matrix array. Furthermore, for layout and circuit simplicity, many address decoders are designed to replace the entire matrix row or column containing the defective matrix cell with a redundant row or column, respectively.
One problem is that after such testing and repair of the matrix array, the redundant array often cannot be tested, and the matrix array often cannot be tested without implementing the repair solution. Such "back-end" tests i.e., tests performed after repair of the matrix array) require a tester that has the capability to determine and store the addresses of the defective matrix cells during matrix-array testing and the unused redundant cells during redundant-array testing and to ignore errors that occur when these dormant cells are accessed. Unfortunately, due to its high cost, such a tester is usually reserved for the initial testing and repair described above, and a much cheaper back-end tester is used to test the matrix array after repair. Although such a back-end tester can test the matrix array with the repair solution enabled, it typically cannot test the matrix array with the repair solution disabled, or test the redundant array after the matrix array has been repaired. Therefore, such back-end testing of the matrix and redundant arrays is rarely, if ever performed.
One reason for testing the matrix array with the repair solution disabled is discussed with reference to FIG. 1, which is a schematic diagram of a portion of a Dynamic Random Access Memory (DRAM) array 10. The array 10 includes a matrix array 11 having rows R.sub.0 -R.sub.N of matrix cells 12 and a redundant array 13 having redundant rows RR.sub.0 -RR.sub.N of redundant cells 14. The matrix and redundant arrays 11 and 13 share common digit lines D and D, which are coupled to a sense amplifier 15. Furthermore, the array 10 incorporates a folded-digit-line architecture such that the cells 12 and 14 in the even rows (R.sub.0, R.sub.2, . . . , RR.sub.0) are coupled to the digit line D and the cells 12 and 14 in the odd rows (R.sub.1, R.sub.3, . . . , RR.sub.N) are coupled to the complimentary digit line D.
During voltage-stress tests of the array 10, a tester drives known logic levels onto the digit lines D and D at appropriate times so as to stress the cells 12 and 14 in a desired manner. Thus, the testing apparatus must calculate the appropriate logic levels with which to drive the external data pins (not shown in FIG. 1) of the array 10 so as to place the desired logic levels on the digit lines D and D. The relationship between the external logic levels and digit-line logic levels is referred to as the data topology of the array 10, which is often abbreviated as the "data topo." Likewise, the testing apparatus must calculate the respective addresses that fire the row lines R and RR. The relationship between the addresses and the row lines is called the address topology, which is often abbreviated as the "address topo." Before the initial testing of the array 10, the testing apparatus is programmed with the array's address and data topo equations so that it can test the array 10 and determine if any of the matrix cells 12 or redundant cells 14 are defective. For example, suppose the tester must drive a logic 1 onto an external data pin to force the sense amplifier 15 to drive a logic 1 onto line D and a logic 0 onto line D. Then it follows that the tester must drive a logic 0 onto the external data pin to force the sense amplifier to drive a logic 0 onto line D and a logic 1 onto line D. Likewise, if the tester reads a logic 1 from the external data pin, it determines that line D is at logic 1 and line D is at logic 0, and if the tester reads a logic 0 from the external data pin, then it determines that line D is at logic 0 and line D is at logic 1. Thus, these known sets of values compose parts of the data and address topos of the array 10.
The implementation of a repair solution, however, may change the data topo, and thus for some matrix rows may change the relationship between the logic level on the external data pin and the logic levels on line D and line D during such tests. When a matrix cell 12 is found to be defective, then the address decoder (not shown in FIG. 1) is programmed to map a redundant row RR to the address of the row R that includes the defective matrix cell 12. For example, if a matrix cell 12 in the row R.sub.0 is defective, then the entire row R.sub.0 is determined to be defective, and the address decoder is programmed to replace the entire row R.sub.0 with a redundant row RR. Because the defective matrix row R.sub.0 is an even row, if the address decoder replaces it with an even redundant row such as RR.sub.0, then the redundant row will have the same data topo as the defective row, and the data topo equations can remain the same for testing the array IO with the repair solution enabled. Conversely, if the defective row R.sub.0 is replaced with an odd redundant row such as RR.sub.N, then the redundant row has a different data topo than the defective row. More specifically, suppose one wants to write logic 1 to the matrix cells 12 in the row R.sub.0. Then according to the data topo described above, the tester writes a logic 1 to the external data pin. If the row R.sub.0 is replaced with row RR.sub.0, then the logic 1 is written to the memory cells 14 in that row as intended, and the data topo remains the same. But if the row R.sub.0 is replaced with RR.sub.N, then a logic 0, not a logic 1, is written to the memory cells 14 in that row, and the data topo is different.
In addition to changing the data topo, the implementation of the repair solution may also prevent certain types of testing from being performed. For example, during a cell leakage test, the tester uses the data topo equations to write a first logic level to a cell 12 or 14 under test and a second logic level to the cells 12 or 14 adjacent to and surrounding the cell under test. (During such a test, the tester can address the array 10 as an entire array having rows R.sub.0 -RR.sub.N instead of two separate arrays 11 and 13 having rows R.sub.0 -R.sub.N and RR.sub.0 -RR.sub.N, respectively.) Storing the opposite logic level in all of the surrounding cells creates a maximum voltage differential between these cells and the cell under test, and thus creates a worst-case leakage scenario for the cell under test. Then, the tester reads the data stored in the cell under test. If the data is equal to the first logic level, then the tester determines that the cell under test has acceptable leakage properties. But if the data is equal to the second logic level, the tester determines that the cell under test is defective because leakage between it and the surrounding cells caused a corruption of the data stored in the cell under test. If the repair solution is implemented, however, one or more of the surrounding cells may be inaccessible, and thus the worst-case leakage scenario may be unattainable for some cells under test. For example, suppose a cell 12 under test is in row R.sub.0, and that row R.sub.1 is defective and has been replaced with a redundant row RR. Often, only one cell 12 in the row R.sub.1 is defective. Therefore, the remaining cells 12 in the row R.sub.1 are available for storing test data to allow worst-case leakage testing of the cells 12 in the row R.sub.0. But with the repair solution enabled, none of the cells 12 in the row R.sub.1 can be written to, and thus the cells 12 in the row R.sub.0 cannot be subjected to a worst-case leakage test. Furthermore, suppose the cell under test is in the last matrix row R.sub.N or in the redundant row RR.sub.1, which are adjacent to the first redundant row RR.sub.0. With the repair solution enabled, the row RR.sub.0 is accessible only if it is used to replace a redundant row. If it is dormant, however, then the cells 14 in the row RR.sub.0 are inaccessible, and the cells 12 in the row R.sub.N and the cells 14 in the row RR.sub.1 cannot be subjected to a worst-case leakage test.
One way to leakage test the entire array 10 after it has been repaired and without calculating a new data topo is to disable the repair solution so that all of the rows, even the defective matrix rows R and the unused redundant rows RR, are accessible to the tester. Although this would allow the tester to use the original data topo, the tester would have to calculate and store the repair solution so that it could avoid reading the defective matrix rows or unused redundant rows, or so that if the tester did read these dormant rows, it could ignore errors from these rows. (Although an unused redundant row may not include any defective cells 14, it may be disabled such that the cells 14 cannot be accessed.) If the tester did not do this, then it would falsely indicate that the part under test is defective, when in fact these defects are already mapped out by the repair solution. But as discussed above, a back-end tester typically cannot calculate and store a repair solution, and a tester that is relatively expensive and thus reserved for initial testing and repair. Furthermore, to increase back-end testing throughput, it is often desirable to test multiple circuits in parallel. Therefore, even if the tester could store a repair solution, it would have to store a different repair solution for each of the circuits. Unfortunately, even the most sophisticated testers often lack the ability to store multiple repair solutions. And even if a tester could store multiple repair solutions, the time required to calculate and store the repair solution for each circuit would be very time consuming, and thus would considerably slow down the testing throughput.
Additionally, changes in the data topo caused by the repair solution may hinder or prevent back-end tests other than the leakage test.